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(57) Abstract: A system and method for memory 
management in a smart card (10) are disclosed. The 
memory manager, preferably part of a true operating 
system, is the single device by which memory in 
the smart card (10) is allocated and deallocated. 
Memory allocation for new data objects and memory 
deallocation as the result of data object deletion are 
made by reference to a memory management record 
(30), preferably a bitmap, which is stored in RAM 
(22) and formed upon smart card (10) initialization. 
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SMART CARD MEMORY MANAGEMENT SYSTEM AND METHOD 

FIELD OF THE INVENTION 

The present invention relates to the field of portable tokens, such as sman cards 
More particularly, the present invention relates to a management system and method for 
memor>' in a sman card. 

BACKGROUND OF THE INVENTION 
Smart cards are increasingly used in financial and commercial transactions m the 
place of credit/debit cards and stored value cards. Rather than employing information 
encoded on a magnetic strip, sman cards include a microprocessor with a memorv' elemem 
embedded within a some physical fomi. With a microprocessor, sman cards interact with 
terminals across a broader range of transactions and are able to communicate a broader and 
a more detailed range infonnaiion regarding the cardholder, a cardholder account, 
transaction authorization, or other inforaiation. 

Fig 1 shows an exemplary sman card 10. Roughly the size of a credit card." sman 
card 10 includes a microprocessor 12 with an integral memory element and conductive 
contacts 13. Microprocessor 12 is typically a single wafer integrated circuit (IC) mounted 
on, or embedded within the otherwise plastic smart card. Conductive contacts 1 3 interface 
with a terminal to electrically transfer data between the tenninal and the smart card. Other 
sman card embodiments do not include conductive contacts 1 3 . Such - contactless " sman 
cards receive infonnation via proximately coupling, such as magnetic coupling, or via 
remote coupling, such as radio communication. 

The microprocessor 12 and conductive contacts 13 of Fig 1, are shown in some 
additional detail in Fig 2. Conductive contacts variously include power contacts, at least 
one input/output (I/O) port, a reset port, and a clock (elk) signal port. Microprocessor 12 
comprises a central processing unit (CPU) 21 which is generically control logic including 
I/O circuitry 23. Tenninal signals variously interface with CPU 21 through the conductive 
contacts 13 and I/O circuitry 23. Microprocessor 12 further comprises a memon. elemem 
20, typically including Random Access Memory (RAM) 22. Read Only Memoiy (ROM) 
24, and Electrically Erasable Programable Read Only Memory (EEPROM) 26. 

Operating power, a user input keypad, and a display for the smart card 
micn)prt>cessor are provided by the tenninal; i.e., an ATM, merchant point-of-sale device, 
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or securin' control device, etc. The terminal includes a mechanism detecting the presence 
of a properly positioned smart card. Upon detecting the smart card, the terminal provides 
power to the microprocessor, and typically sends a reset (RST) signal to the sman card. 
The sman card uses the RST signal to reset itself or to initiate an intemal reset ftinciion. 
After reset, the smart card returns an answer-to-reset (ATR) signal to the terminal. The 
ATR signal communicates basic information conceming the smart card to the lermmal. 
Once such basic information is successfully recognized by the terminal, communication, 
i.e., data transfer, between the smart card and the terminal can be established. 

In addition to operating as ATM cards, credit/debit cards and stored value cards, 
sman cards can be designed to operate as personal identity cards, critical record storage 
devices. securit\' IDs, etc. In these varied capacities, a smart card may be designed to 
perform any number, or any combination of data processing functions including, access, 
storage, transfer, exchange, authorization, etc. 

.As sm^n cards are pressed into service to suppon an increasingly broad range of 
applications, the demands placed on the smart cards' memory system increase 
dramatically. Conventional smart cards have not required tme memory management since 
memor}' system performance expectations have been very modest. However, if sman 
cards are to realize their full potential of nmning a number of independently developed and 
controlled applications on a single card, an effective, secure memory management system 
must be implemented. 

In early examples of conventional smart cards, an application was stored in ROM 
and nm as an embedded application directly on the microprocessor. Later examples of 
conventional smart cards incorporated an interpreter in ROM and/or allowed applications 
to be written into EPROM. In any of these configurations, the conventional sman card 
memory was accessed and manipulated by any and all applications and/or interpreters 
running on the smart card. The security problems associated with multiple programs 
accessing the same memory space are one factor historically militating against the use of 
multiple applications on a single smart card, particularly multiple applications from 
different vendors. 

Thus, conventional smart cards have rarely been required to tmly "manage'' their 
memory space. Some static or even movable boundaries between segments of memor>' 
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have been used but such boundaries: e«--' o-u-h- . ' ' 

allocation. ' P"™""' ^P^"^ 

European patent document 0 29'' 748 

uxncni u .y. 248 discloses one conventional smart card 

and a movable bounda^ „ , ^^^^^^^ H 

from a r=ad/™,e ponion of EPROM spring otterda-a wpes 

such macro-panmomng of EPROM b«w«„ da« ^ „. 
apphcauons .s _ i„ eonvendona, s^an card.. Often. d» partdomng creates a f.ed 
^mo. ,„cuc in Which o„. appucadon . 

Once d,e ,ueue is m no additional ^ ^ „„„ ^ 
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SUMMARY OF THE INVENTION 
The present invention provides a single memory manager, preferably pan of a true 
operating system (OS), through which sman card memory is allocated and deallocated. 
Since all requests for sman card memor\' definition (allocation and deallocation) are 
5 controlled by the memory manager, memory integrity and security are assured. 

Since memory allocation may be made dynamically on an as-needed basis, the 
smart card memor>' may be efficiently used, and need not be pre-allocated or defined by 
arbitrary boundaries. 

In allocating and deallocating memory space, the memory manager references a 
10 memor}' management record, typically a bitmap or similar record. During sman card 

operation, the memory management record is preferably stored in RAM. Accordingly, the 
memor>- management record must be recreated in RAM upon sman card initialization. 
This may be done by recopying a copy of the memory management record previously 
stored in non- volatile memory by a previous transaction ending in a controlled shut-down, 
15 or by poling a file directory stored in non- volatile memory following a transaction ending 

in an uncontrolled shut-down. 

The memory management record may include a broad array of infomiation relating 
memory to various data objects stored in memory. Primarily, however, it indicates 
memory availability. 

20 The present invention makes full use of a predictable data record format and an 

efficient file directory structure. While subject to variation and programmer definition, the 
data record format provides a basis by which the memory management record may be 
recreated upon sman card initialization by interrogation of the various data object stored in 
read/write memory. The file directory is flexible and able to accurately identify all data 

25 objects persistent in read/write memory, while occupying a minimiun of memory space 

itself. 

A file manager, also preferred as pan of the OS, is used to access data records in 
the file directory. Together with the memory manager, the file manager allows read/write 
memory to be efficiently allocated and deallocated. Read/write memory space may, in 
30 fact, be recycled once a former data object is no longer needed. 

Thus, the present invention in it multiple aspects provides a system and method by 
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which memory in a smart card is securelv»«w^«e..:..-,.^ ..,^. . 

"-u-c-., ^,^et,u vci y usea. as Detween multiple 

apphcauons running on the sman card. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 illustrates an exemplary conventional smart card; 

Fig. 2 illustrates the integrated circuit portion of the conventional sman card is 
some additional detail: 

^ Fig. 3 illustrates one example of a memory management record according lo the 

present invention: 

Fig. 4 illustrates one example of a data record format according to the present 
invention: 

Fig. 5 illustrates one example of a file directory structure according to the present 
10 invention: 

Fig. 6 is a flowchart illustrating a method for forming a memory management 
record in RAM upon sman card initialization: 

Fig. 7 is a flowchart illustrating a method for allocating memorv and forming a data 
record in the file directory; and, 
15 Fig. 8 is a flowchart illustrating a method for deleting a data record from the file 

director)' and deallocating the associated memorv. 
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DETAILED DESCRIPTION 
Th= presen, .„v.„,io„ provides a .„g,e „a„.,er for „ , ^„ 

- ope.„„8 s.s,en, or ,y an application, is „ade trough «s single n,™orv .ana.„ ' 

No oAeragem can access or define ™emo„ space on U,esn,» card ' ~ ' 

0U,ers c'"'tr'"'' ■"-■"^ --gemen, capabi,i,ies. amongs, 

0U,ers capab,ln,es. .s .esiden, in *e sman card operanng sys«n, (OS). The OS is " 

« „ ROM. bu. ™ay be sro^d. wholly or in pan in read/wrire n,e™on . The 
OS .s a ^e OS „ *e sense U,a, i, does no. exec„„ any co^nand received from a 
— Rad,er. U,e OS provides an UO .u,ine by wh.ch con^ands are .ra„sfe.ed fro„ 
.he ,enn,nal ,o an applicauon rumdng „„ ,he sn,an card, and provides a number of 
•uncions wMch .ay be called by any one of .he sman card applicauons. The «nn 
-fimcuon.- as ..ed in *e con.ex. of OS capabUines. deno.es a se. of .,a«d opera.iona, 
flmcnons. .ns.ruc.,o„s. processes, and/or defl„i.i6„s which have been convenien.lv 
gmuped or idenrified .ogcher according .o d,eir nanire or opera^ona, relaUonship; 

The n,en,ory manager of a,e present invention is preferably one such OS function 
The .enn "memon, manager" is used ,o denote tite code providing a. leas, tite memorv ' 
allocation. deallo«tion, and accounting capabilities discussed in gteater detail below' The 
memoty manager manages all data sto.ed in tead/write memory and RAM. including' as 
examples. scra.ch pad da.a. file/record data, and applications. The term -read/wn.e 
memon- is used .o geneHcally refer .o those fonns of memory into which data mav be 
™»en and read. .^11 fonns of electiically programmable read only memorv (EPROM , 
and flash memory are con.empla.ed by .he ,emi read/write memorv. 

The single memory manager of tite presen. invention implement a flexible 
controlled memory access capability for .he OS and all apphcations on ti,e sman card a. 
tile lowes. level of read/wri.e memorv. Bv use of the sinttle m,m„™ 

■ - ^°'™""8'e memoty manager, applications 

are stored in efficientiv allocated memorv snam n,™„ 

memory space. There are no requirements for memory 

space to be pre-ailocated to an application when it is installed, as is often the case with ' 
conventional sman catds. In ftct. with tiie exception of a very limited set of dobal data 
objects: tile entiren. of read/write memoiy may be used by the memorv manager ,o 
dynamically store records, files and data objeos for tiie opera.ing svs.em and tiie 
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applications on the sman card. 

Memory allocation is made by the memory manager on an "as needed" basis, such 
that records, files, and data objects are stored in a minimum of memorv' space. When the 
OS or an application requires a block of memory, it requests the desired amount from the 
5 memor>* manager. The memor\' manager identifies and allocates the smallest available 

block of read/wTite memor>' capable of satisfying the request. This process reduces 
memor\' space fragmentation and allows optimal use of the memory space. 

Effective memory management requires a reference. At any given moment, the 
reference must accurately indicate which ponions of memory are in use and which 
1 0 portions are available for allocation. .Alternatively, an accounting or a poling algorithm 

might be used to monitor memory use. 

A memorv' management reference can take advantage of the fact that commercial 
memorv- devices are often divided into data blocks having a minimum or nominal size. 
For example. EPROM is nominally divided into N data blocks. At present, commercially 
15 available EPROM is divided into data blocks of 16 bytes per block, but EPROMs having 

32 and 64 byte data blocks are readily foreseen. In the examples which follow. 16 bytes 
data blocks are assimied as a convenient granularity for the definition of read/write 
memory space. 

Of critical importance, the reference by which the smart card memory is managed 
20 must always be accurate. Because smart cards are routinely used in fmancial transactions. 

they are constantly subjected to hacker anacks. In one class of favored attacks, generally 
referred to as "card yanks." a hacker will monitor the memor>' state of a sman card during 
critical periods of a fmancial transaction in which data is being wrinen to the sman card- 
Within such periods, the memory may, in whole or in pan. transition through an undefined 
25 state. Once potential periods of undefined memory state are identified, the hacker 

terminates the transaction during these periods in an attempt to acquire an imdefined 
memory state, which will later be interrupted in a subsequent transaction as having a 
substantially higher value than that otherwise authorized had the interrupted transaction 
nm to completion. 

30 Accordingly, in one aspect, the present invention precludes such attacks by never 

allowing an erroneous or undefined memory state to arise from the memory management 
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r=fe™,«. Hereafter, refe,«,ce. in whatever fon„ , „ ac^ally impiemei-ted. „i„ be 
tenned a "memory managemem record/' 

Wirt„ ,he present .nvemion. the „em„„ n,anageme„t record i. preferablv stored 
.n RAM. RAM U preferred because it may be access^ (tead to or wrinen fron,, in a 
stngle data transfer cycie. (The exact timtng for this cycle is defined by the microprocessor 
and the ntetno^. device used on the stnan card,. ,n conttast. ,ead/„ri,e mentorv reputes 
multtpie cycles to wtrte dat. and is thus susceptible to catd yanks. Other -fast" memon- 
elements may be t^ to store the memory managemem record, such as the SRAM ' 
assoctatedwid, the smart card microprocessor. However, single cycle data access is 
genetally re,mred ,„ insure the accuracy and security of the memory management record 
The memory managemem record may take many fotms. A, present, a bitmao table 
preterred. but a set of tables or an algorithm m,gh. also be used. Refetring to Fi/ an 
exen,plan- bitmap table 30 is illustrated .„ three columns. Each column rep^esents'a data 

held having Nentnes. Eachent^.O. 1- ... N-l. N) co-responds to a data block withtn the 
i -5 read/^\Tite memory . 

A firs, data field 3. includes N entries, each entry indicating whether an associated 
data block ,s cutrently in use. Use or non-use may be indicated bv a single bit 

A second data field 32 also includes N entries. Each second data field entr,. 
.ndteates ownership for the associated data block. ITte tem, "ownetship" denotes an 
access authorizaUon or relaUonship between one or more sman card programs „he OS or 
an application, and the data block. That is. each entty in the second data field i„cluae= 
um,ue ow^rship infonnation identifying which programts, on the sman card are acle to 
access the data block. For example, assuming a single. 8-bi, ownership bvte. FO m,.h. 
.ndtcate U«, a data block is owned by the OS. Whereas, data block -y i„ the examrie 
shown m Ftg. 3 is owned by an application identified by the ownership bvte -e'' - Use of 
a un„ue ownership byte for each data block p^vents one application from accessing dau 
owned by the OS or by another application. Of note, ail dau blocks not curr^tv in "use 
are typically defined as being owned by the OS. 

A third data field 33 also includes N entries. Each entry in the third data field 
indicates an access type for the associated data block. The range of possible access rvpes 
mcludes. for example. Read-Only, Read/Write. Lock, and Free. Further, the access pe 
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may indicate a security access condition for the data block. 

The memory manager uses the memory management record to efficiently allocate, 
account for, and deallocate memor\' space. For example, when requiring additional 
memor>- space, the OS or an application will "call" the memory manager. The term -call" 
5 or "calling" is used throughout to broadly describe a relationship between two pieces of 

code in which one piece invokes the other. Once called, the memor>' manager receives a 
request for a block of read/write memory. Based on the size of the requested space, the 
present availability of read/ write memory space, and the nature of the requesting program, 
the memory manager will allocate the requested space. 

1 0 With benefit of the memory management record. memor>' allocation and 

deallocation are straight forward. Using the example illustrated in Fig. 3. the memorv- 
manager simply updates the information stored in the second (ownership) data field, and 
changes the use indicator in the first data field for each data block allocated/deallocated by 
a request. Further, the memory manager may monitor or account for memorv' space by 

1 5 interrogating the memory management record. 

Referring to Fig. 3, it is assumed as an example, that the application having an 
ownership byte indication of *'62" requested an additional 32 bytes of memory space. The 
memory manager determines to allocate data blocks 4 and 5, each block being 16 bytes in 
size, to fill the request. Accordingly, the memory manager changes the data in the first 

20 data field to indicate that data blocks 4 and 5 are now in use. and changes the ownership 

byte in the second data field from 'TO." the ownership indicator for the OS. to "62." the 
application's unique ownership indicator. At this time, the memor>' manager might also 
change the access type indication in the third data field. 

Memor\' space deallocation is similarly performed. Once data blocks in read write 

25 memor>' are retumed to OS ovmership and their '*not-in-use'' status indicated, they may be 

reallocated during subsequent requests for memory space. In this marmer. memor>' space 
may be intelligently and securely allocated and deallocated between the OS and an\ 
nimiber of sman card applications. 

The RAM-based, memory management record thus provides an ideal vehicle for 

30 the memory management. Since RAM is fast, the memory management record may be 

readily updated in a single access cycle to reflect any change in memory use, ownership, 
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and/or access type for one or more reaci/^vrite data blocks. Unfonunateiv. RAM .s also a 
volatile memory incapable of retaining data when the smart card loses power By the.r 
natt^e and t^e. smart cards often lose power. In fact, at the end of many transactions a 
termmal will unceremomously termmate power to the smart card without wamina Thus 
the presence of a memon^ managemem record in volatile memory requires additional 
considerations. 

In those circumstances where a temiinai provides a "controlled shut-down ' the 
memon- managemem record may be easily preserved by copying it into read/write 
memory. Upon being subsequently reactivated, the memory managemem record will be 
recopred into RAM as part of a smart card initialization routine. A controlled shut-down .s 
any transaction ending evem which communicates the impending loss of power to the 
sman card with sufficiem remaining time for the sman card to copv the memor^• 
managemem record into read/write memor>^ When copying the memorv management 
• record mto read/write memory during a controlled shut-down, the OS mav include a 
security signature with the file in order to authenticate the file before it is recopied into 
RAM during a subsequent transaction. 

However, in those circumstances where power is terminated to the smart card 
wrthout adequate notice or time to allow the smart card to copy the memorv management 
record mto read/write memory, i.e., following an "uncontrolled shut-down." the memor^- 
managemem record must be reconstructed from the data stored in the non-volatile 
read/write memory. 

Thus, in another aspect of the presem mvemion. reconstruction of the memon 
managemem record is performed during a subsequem initialization routine bv the memon- 
manager which draws upon information stored in non-volatile memory to accurateh- 
reconstruct the memory managemem record before the smart card memorv is accessed 
This ability or requiremem to reconstruct a RAM-based memory managemem record from 
non-voIat,le memory implicates the nature and structure of the data records stored in 
read/write memory. 

In order to property reconstruct a memory managemem record, everv relevant file 
record, data object, or application must be stored in non-volatile memory in some fonn 
recognizable to the routine which reconstructs the memory managemem record. Onlv data 
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stored in non-volaiile memory survives a loss of power. Accordingly, all data intended to 
be "persistent" must be stored in non- volatile memory. For purposes of the explanation 
that follows, the non-volatile read/write memory element is assumed to be an EPROM. 
However, as previously noted, other r\'pes of non-volatile memory might be used. 
5 A "'data record'' structure is defined for all data stored in read/write memor>' which 

is intended to be persistent. This structure is recognized by the memory manager which is 
able to recreate the memory management record following an uncontrolled shut-down. As 
one of ordinary skill will understand, the exact nature, size, and characteristics of the data 
record structure are left to the individual programmer. The example which follows is 

1 0 merely a presently preferred example. 

A data record may be an application, a file, a record, a data object or any other type 
of persistent data. Fig. 4 illustrates an exemplar)' 16-byte data record structure comprising 
a 2-byte ID field, a 1 -byte ownership field, a 1-byte i\'pe field, a 4-byte data field, a 2-byte 
data length field, and a 6-byte label field. As presently preferred the r\'pe field and the 

15 label field are user definable. That is. an application's programmer may use these data 

record fields for any purpose whatsoever. The memory manager, and the OS in general, 
do not care what these fields contain. They are merely variable data fields associated with 
a data record. As examples, the t\'pe field might indicate whether the data record is an 
application, a file, or some other data object. The label field might indicate an access type 

20 or condition for the data record. 

The ID field identifies the data record within the file system administered by the 
OS. The ownership field includes ownership infomiation. In the present example, the 
ownership field of the data record contains the unique ownership byte previously 
described. Only the OS may access and define the ID and ovraership fields in each data 

25 record. 

The data field and the data length field are related within each data record. The 
data length field specifies the size of the data field. In one preferred embodiment, the data 
field is allocated 4 bytes, it's maximum data size. Thus, if the data length field indicates 
that the data is 4 bytes or less in size, then the data field stores the actual data associated 
30 with the data record. If, however, the data length field indicates that the data field is 

greater than 4 bytes in size, the data field stores a 4-byte data pointer indicating the 
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begtaung addrc^, „«„here in read,„ri,c memory ac which the ac:uai daa mav be found 

By mKrpreting tee Helds for each dara record, the ownership, dau len.U, and 
data fields in panicular. Ae memory manager i. able .o reconstruct the memon " 
managemem record from the data records stored in read/write memory. 

The foregoing capability requires that all data records be stored or referenced 
u .thtn the read/write memory. As presenUy prefened. a sman card according to the 
present .nventron organizes and mat^ges data records by use of a "file manager ' in 
conjunction with one or more file directories. The file manager is anoUier fl^cfon 
restdent in the OS. and may be called by the OS or by an application nmnin. on the sman 
card. The file manager provides geneml dau record storage and retrieval serMces The 
nle manager oi*e„ works in cooperatton witi, the memoty manager to accomplish a varien- 
Of .asks. In tact, one or ordinary skill will recognize that the functtonal panition between ' 
the file manager and d,e memory manager presented herem is arbiuarilv draw, accordino 
.0 presem preferences. These preferences relate to efficient program definition and clear' 
programmmg explanation. The file manager, like all other OS flmctions in dte presem 
mvenlion. may be implemented in many specific fonns. 

m order to understand the file manager and ifs operative relationship to the 
memory manager and d^ memoty managemem record, one must first determine or define 
a file managemem reference. A table or tree defining a file directory is presentiv preferred 
as a file managemem reference but other programming devices mijht be used 

Fig. 5 illustrates a file directoty. The file director, comprises N entries T.„ are 
shown as an example. Each entry is able to store a 16 byte data record havtn. the stmcure 
prevrousiy described. Thus, beginning at some stanmg address, which mav be defined 
wtthm the OS or by some global vanable upon first initialization of the smart card a first 
(or root) file directory is created in read/write memoty. In other words, upon first 
acttvating the sman card, the OS or a boot-program applicadon stored in ROM creates a 
1 60 byte long root file directory in read/write memoty before the OS or an application 
defines a first data record. 

Once the root file directory is created, the file manager stores the first N-1 data 
records defined on the sman card as the first N-1 entries. If an Nth data record .s required 
the root file directory is linked to a second file directory in read/write memoiv v.a a 
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"LINK'' data record stored as the Nth entry of the root file directory. Prior to the moment 
in which an Nth data record is stored, the Nth entry of the root file directory contains a 
''END" data record. The END data record indicates that no additional data records are 
stored in read/write memory. In contrast- the LINK data record directs the file manager to 
5 another file directorv'. Any number of file directories may be linked in this manner lo 

accommodate a large number of data records. 

END and LINK are special t>'pes data records which are used by the file manager to 
effectively interrogate and manage file directories in read/write memory. The ID or t>pe 
data fields in the END and LINK data records may be used to indicate their special nauire 

10 to the file manager. For the LINK data record, the data field may be used to store a pointer 

to the beginning address of the next file directory and the data length field will indicate the 
data length - 1 60 bytes in the working example. Accordingly, in one embodiment, the OS 
will always own the Nth entry of each file directory, which will contain either an END data 
record or a LINK data record. 

1 5 Thus, at the moment that some program on the smart card seeks to define an Nth 

data record, the file manager calls the memory manager requesting allocation of another 
160 bytes of read/ write memory. Once allocated by the memory manager, the 1 60 bytes 
are defined as a second file directory, and the starting address of the second file directory is 
linked to the root file directory by changing the Nth enir\' of the root file director.- fi-om an 

20 END data record to a LINK data record, and by storing the staning address for the second 

file directory in the data field of the LINK data record. 

File directories may be searched or queried by the file manager. That is. the ilie 
manager may search a file directoiy using any one or more of the data record fields. Thus, 
a specific data record may be located by searching for its ID field, or all data records 

25 owned by a particular application may be readily located by their ownership field. By 

using the t\'pe field and/or the label field, for example, an application developer may 
define a specific record access mechanism based on a imique securit\' requirement in the 
application. Such a mechanism may then be implemented and controlled using the file 
manager. 

30 With an understanding of the preferred data record structure and the file manager, 

the formation of the memory management record, in this example a bitmap according to 
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Fig. 3, by the memor>' manager will now be explained with reference to the flowchan 
shown in Fig 6. 

Upon receiving power, the smart card begins a start-up routine 60. As with 
conventional smart cards, the start-up routine may begin with receipt of a RST signal from 
the terminal. At some point in the start-up routine, an ATR signal is returned to the 
terminal. However, before beginning an I/O routine to receive a command from the 
terminal, die smart card must form the bitmap in RAM. Since the smart card may have 
shut-down in either a controlled or uncontrolled manner at the end of the previous 
transaction, the memory manager must determine whether a copy of the previous sessions 
bitmap is stored in EPROM f61=yes). The presence of a stored bitmap might be indicated 
by the state of a global variable in EPROM which is interrogated during the sian-up 
routine. 

If a bitmap copy is stored in EPROM. the copy is located 62. If the bitmap copy 
includes a security signature (63=yes), the signature is authenticated 64, and if the 
15 signature is valid (65=yes), the bitmap copy is stored in RAM 67 and the routine is ended 

75. It however, the signanire is not valid (65=no), the start-up routine is halted and an 
error message 66 is returned to the terminal. If the bitmap copy does not include a security 
signature (63=no), it is simple stored in RAM 67 and the routine is ended 75. 

If a copy of the previous session's bitmap is not stored in EPROM (61=no). the 
20 memory manager must recreate the bitmap from the data records stored in EPROM. To do 

this, the memory manager calls the file manager 68. and the file manager begins with the 
first entry in the root file directory and obtains a data record 70. The ownership and t>'pe 
fields are identified fi-om the obtained record 71. 

Next, the file manager determines whether the data field is empt>' 72. This 
25 determination may be made on the basis of the contents of the type field, or by directly 

examining the data field, or the data length field. If the data field is empty (72=yesj. then 
the file manager determines whether another data record is present 69. This determination 
may be made by reading the next data record in the root file directory to see if it is an END 
data record. Once an END data record is found, the bitmap formation routine ends 75. 

however, the data field is not empty (72=no), the data length field value, the 
ownership field information, and the access type information are returned to the memory 
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manager 73. The memory manager then writes this information to RAM as one bitmap 
entrj' 74. The memory manager again calls the file manager 68 and the process continues 
until the END data record is found. 

Using this routine, the three data fields of the bitmap shown in Fig. 3 mav be 
created in RAM. More or less informaiion may be transferred from the data records to the 
memor\ management record depending on the nature and content of the memor>' 
management record. 

An exemplary routine by which a new data record is formed is explained below 
with reference to the flowchan in Fig. 7. In this example, it is assumed that the smart card 
has been successfully activated. Accordingly, a file directory in stored in EPROM. a 
memor>- management record has been formed in RAM, and the sman card ready to receive 
a terminal command. 

WTiile in this BEGIN state 77. a command is received 78. Preferably, the OS 
controls the I/O routine, and upon receiving a command the OS seeks to identify the 
application ovming the received command 79. This might be done by comparing an 
ownership byte communicated in the command with the ownership byte for each 
application type data record stored in the file directory. The type data field of the data 
record stored in the file directory can be used to readily indicate which data records which 
are appUcations. If failing to identify an owning application (79=no ), the OS will call an 
error routine to identify the failure to the terminal 83. 

After identifying the owning application ('79=\'es). the OS will call this application 
and communicate the conmiand 80. In this example, the application receives a command 
to "Store Data.'' where the data to be stored is 100 bytes in size 81 . In order to store the 
data, the application must first be allocated sufficient memory space by the memor\- 
manager. Thus, the application calls the memory manager 82. 

If the memory manager fails to identifies 100 bytes of available space (84=noK the 
error routine is called to indicate this fact to the terminal 83. Assuming the memory- 
manager identifies 100 available bytes of memorv% the memory management record is 
updated to allocate the space to the requesting application 85. 

The file manager is called 86, and inserts the data into the allocated memor\ space 
in order to create the requested data record 87. The file manager then defines the 
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appropriate data fields in the next available file directory entry to reflect the nature of the 
new data record 88. At this point, the new data record is persistent in memory, and the OS 
ends the routine 89. 

Data records may be deleted for any number of reasons. For example, an 
application might be wholly deleted from the sman card taking everx' associated data 
record with it. Some data records may be time sensitive. That is. some data records may 
be valid for only a limited period of time, or a limited number of transactions. Once the 
time period or other condition expires the data record is deleted. 

No matter what the reason, an existing data record may be deleted and its 
associated memory space deallocated and returned to the OS for future use. In this 
mamier. memor>- space is actually recycled within the smart card of the present inN-eniion. 

•An exemplan- routine by which a data record is deleted is explained with reierence 
to Fig. 8. It is assumed that an application has received from the terminal via the OS a 
••Delete Record" command 9 1 . Alternatively, a "Delete Record" request might result trom 
some other terminal command being implemented in an application. In any event, upon 
receiving a "Delete Record" conmiand, the application calls the file manager 92. 

The file manager locates the data record in the file directory by. for example, 
looking for a specific ID field 92a, changes the information in the ownership data field for 
the located data record fi-om its present state to one indicating OS ownership 92b. and 
changes the type field of the located data record to indicate that the associated file 
directory' entry in now emprv 92c. 

Once the file manager is done, the memory manager is called 93. The memor> 
manager updates the memor>- managemem record 93a to reflect the deallocation of 
memor>' space previously associated with the deleted data record. For example, taking the 
bitmap example of Fig 3. for each data block once allocated to the deleted data record, the 
first data field is changed to indicate "not in use," the second data field is changed to 
indicate OS ownership, and any type access information in the third data field is cleared to 
indicate "fi-ee' access. 

Using the principles and relationships above, a memory manager and a file 
manager used in conjunction with a memory management record and one or more file 
directories may efficiently allocate, account for, and deallocate memory space in an 
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environment where integrity of the memor>' at any moment is ensured. As used above, the 
file manager and the file directory replace the unwieldy file tree structure suggested by ISO 
7816, pan 4. Scarce memory space may be recycled for use by the smart card. 

In sum. the present invention provide a platform upon which a smart card may 
download and rtm a multiplicity of applications from different sources, without beaching 
data security between the applications, and without inefficiently partitioning memor\' 
according to application. 

The foregoing examples have been presented to teach the novel nature and 
relationships between at least the smart card operating system, the memory manager, the 
file manager, the memory management record, one or more file directories, and 
applications ninning on the smart card. By its very nature, software development yields a 
great varieties of variations and resulting structures. With this in mind, the present 
invention is not limited to the examples above, but is defined by the anached claims. 
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What is claimed is: 

l.Asmm card system receiving commands from a terminal, and comprising: 
a microprocessor and a memory element, the memory element storing at least one 

application and an operating system (OS), the OS comprising a memory manager: 
wherem only the memor>' manager allocates memor>' space in response'to a 

command. 

2. The system of claim L wherein the memory element comprises Random- 
Access-Memory (RAM), read/write memon', and Read-Only-Memory (ROM), and 
wherein the memory manager allocates space in read/write memory in response to the 

1 0 command. 

3. The system of claim 1. wherein the OS is incapable of executing any one of the 
commands. 

4. A method of allocating or deallocating memorv- space in a smart card 
comprising a microprocessor and a memory, the smart card receiving commands from a ' 

15 temiinal and the method comprising: 

storing an application in memory; 

storing an operating system (OS) in memory, the OS comprising a memor>* 
manager; 

upon receiving a command from the terminal requiring allocation of memorv 
space, using only the memory manager to allocate the memory space. 

5. The method of claim 4. wherein the memory comprises Random-Access- 
Memoiy (RAiM). read/^^'rite memor>-, and Read-Only-Memory (ROM), and wherein the 
OS is stored in ROM. and the memory manager allocates memor>' space in read/write 
memory. 

6. A system managing smart card memory, the memory comprising a 
a first memor. portion and a second memory portion, and the system comprising: 

a memory management record stored in the first memory ponion indicating use of 
the second memory portion. 

7. The system of claim 6, wherein the state of data stored in the first memor%- 
ponion is never undefined for a period of time 'greater than one data access cycle. 
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8. The system of claim 6. wherein the first memory ponion comprises a Random- 
Access-Memory (RAM), and the second memory ponion comprises an Electricaily- 
Programmable-Read-Only-Memor\' (EPROM). 

9. The system of claim 7, wherein during activation of the sman card, the memor>' 
5 managemem record is stored in the first memory ponion, and upon a controlled shui-dovvn 

of the sman card, a copy of the memory management record is stored in the second 
memorv' ponion. 

10. The system of claim 9. wherein a security signature authenticating the copy of 
the memory management record is also stored in the second memory portion following a 

10 controlled shut-down. 

1 1 . The system of claim 7, wherein at least one data record is stored in the second 
memor>- ponion. and wherein upon activation of the sman card following an uncontrolled 
shut-down, the memorv- managemem record is created in the first memory ponion by 
reference to the at least one data record stored in the second memor\' ponion. 

15 12. The system of claim 8, wherein EPROM is divided into N data blocks, and 

wherein the memory management record comprises a bitmap table stored in RAM and 
having N entries, each one of the N entries comprising a first data field, and each one of 
the N entries in the first data field indicating current use for a corresponding one of the N 
data blocks in EPROM. 

20 13. The system of claim 12. wherein each one the N entries in the tirst data field 

comprises a single bit indicating whether or not the corresponding one of the N data blocks 
is currently in use. 

14. The system of claim 12. wherein each one of the N entries in the bitmap table 
further comprises: 

25 a second data field indicating ownership of a corresponding one of the N data 

blocks of EPROM. 

15. The system of claim 14. wherein each one of the N entries the bitmap table 
further comprises: 

a third data field indicating an access control status for a corresponding one of the 
30 N data blocks of EPROM. 
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1 6. The system of claim 15. wherein the access control status defines at least one 
state from a group of states consisting of free access, read/write access, and read-only 



access. 



1 7. A method of managing a smart card memor>-. the memor>' comprising a 
a first memory ponion and a second memor>- portion, and the method comprising: 

storing a memory management record in the first memory ponion which mdicaies 
use of the second memory ponion. and 

allocating space in the second memory ponion b>- reference to the memory 
management record. 

' ^- '^^^ "'^^^'^ °f '^laini 1 7. wherein the first memory ponion comprises a 
Random-.Access-Memory ^RAM), the second memoiy ponion comprises a read v^Tite 
memor\-. and the method fiinher comprising: 

storing at least one application and an operating system (OS) primaril> in ROM. 
wherein the OS comprises a memor>' manager solely capable of allocating read, uriie 
15 memory space; and, 

storing at least one data record associated with the at least one application in 
read/write memor\-. 

19. The method of claim 1 8, wherein a first transaction between the sman card and 
a terminal may be terminated by either a controlled shut-down or an uncontrolled shut- 

20 down, the method fiuther comprising: 

upon tenninating the first transaction in a controlled shut-dou-n. copying the 
-Tiemon. management record from R.A.xM to read/write memor>-. 

20. The method of claim 1 9. further comprising: 

storing a security signature authemicating the cop> of the memor>- management 
25 record in read/write memor>-. 

21. The method of claim 19. wherein upon beginning a second transaction 
between the sman card and a tenninal. the second transaction following tennination of the 
first transaction, the method further comprises: 

detennining whether a copy of the memon' management record is present in 
read/write memory, and upon determining that a copy of the memory managemem record 
is present in read/write memory, recopying the memory management record imo RAM. 
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22. The method of claim 19. wherein upon beginning a second transaction 
between the smart card and a terminal, the second transaction following termination of the 
first transaction, the method further comprises: 

detemiining whether a copy of the memory management record is present in 
^ read/uTite memory, and upon determining that a copy of the memory management record 

is not present in read/write memory, creating the memory management record in RAM by 
reference to the at least one data record. 

23. The method ofciaim 20, wherein upon beginning a second transaction 
between the smart card and a terminal, the second transaction following termination of the 

1 0 first transaction, the method further comprises: 

determining whether a copy of the memory management record is present in 
read/write memor>', and upon determining that a copy of the memor\' management record 
is present in read/'write memor\% authenticating the stored security signature, and upon 
successful authentication the seciuit\' signature, recopying the memory management record 

15 intoRAiM. 

24. A method of managing memory in a smart card, the smart card comprising a 
microprocessor and a memory, the memory comprising Random- Access-Memor>' (RAM), 
read/write memory divided into N data blocks, and Read-Only-Memory (ROM), and the 
method comprising: 

-0 defining in RAM a memory management record having a first data field of X 

entries, each one of the N entries in the first data field indicating for a corresponding one 
of the N data blocks in read/write memor\', whether the corresponding one of the N data 
blocks in read/write memorv' is currently in use. 

25. The method ofciaim 24, wherein the memor>^ management record further 
25 comprises a second data field of N entries, each one of the N entries in the second data 

field indicating ownership for a corresponding one of the N data blocks of read/ write 
memory. 

26. The method ofciaim 25, wherein the memor\* management record fiirther 
comprises a third data field of N entries, each one of the N entries in the third data field 

30 , indicating an access control status for a corresponding one of the N data blocks of 
read/write memory. 
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27. In a sman card comprising a microprocessor and a memory , ihe memor> 
storing an operating system (OS) and at least one application, the OS comprising a file 
system and the memory storing a data record, the data record comprising: 

an identification (ID) field uniquely identifying the data record within the file 
system: and. 

an ownership field idenafying at least one owner for the data record. 

28. The data record of claim 27. wherein only the OS is able access the ID field 
and the ownership field. 

29. The data record of claim 27, wherein the data record further comprises: 
a type field defining the nature of the data record within the file system; 

a data field, and 
a data length field: 

wherein the data length field specifies the size of data associated with the data 
record, and the data field stored the data when the data is of a size not greater than a 
15 maximum data size. 

30. The data record of claim 29, wherein the data field stores a pointer to the data 
when the data is of a size greater than the maximum data size. 

3 1 . A method of managing memory in a smart card comprising a microprocessor 
and a memory, the memory comprising a volatile memory portion and a non-volatile 
memoiy portion, the non-volatile memory portion storing at least one application, an 
operating system, and a plurality of data records associated with the at least one 
application, the method comprising: 

upon activating the smart card, forming a memorv- management record in the 
volatile memory portion by reference to the plurality of data records. 

32. The method of claim 31, wherein the non-volatile memory portion is divided 
into N data blocks, and wherein each one of the plurality of data records comprises an 
indication of the size of data associated with the data record, wherein fonning the memory 
management record further comprises: 

interrogating each one of the plurality of data records: and 
in accordance with the indication of data size for each one of the plurality of data 
records, defining a portion of a first data field witiiin the memory management record. 
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33. The method of claim 32. wherein the first data field comprises N entries, each 
entry corresponding to one of the N data blocks, wherein the defining of a portion of first 
data field within the memory management record further comprises: 

defining one or more of the N entries in the first data field in response to the 
5 indication of data size for each one of the pluralit>' of data records. 

34. The method of claim 31. wherein the non-volatile memor\' ponion is divided 
into N data blocks, and wherein each one of the plurality of data records comprises an 
ownership field containing ownership information for the data record, and a data length 
field indicating the size of data associated with the data record, the method comprising: 

10 interrogating each one of the plurality of data records, and for each data record: 

defining a ponion of a first data field in the memory management record in 
accordance with the data length field of data record: and 

defining a ponion of a second data field in the memor\' management record in 
accordance with the ownership field of the data record. 
15 35. The method of claim 34, wherein the data records are arranged in a file 

director}' stored in the non-volatile memory portion. 

36. The method of claim 35, wherein the file directory comprises M entries, each 
one of the M entries capable of storing a data record or an END data record. 

37. The method of claim 36. wherein interrogating each one of the data records 
20 further comprises : 

traversing the file director}- entr\' by entr\- until finding an END data record. 
- 38. The method of claim 37. wherein the file director}' comprises a root file 
director}' and at least one additional file director}', wherein each one of the M entries is 
further capable of storing a LINK data record, such the root file director}* and the at least 
25 one additional file directory are linked in memory by a LINK data record. 
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39. A method of defining a data record in smart card memory, the memor\ storins 
an application and an operating system (OS) having a memory manager and a file 
manager, the method comprising: 

receiving a command in the OS from a terminal: 
:^ transferring the command from the OS to the application: 

reading the command in the application and determining that the command 
requires the formation of a new data record in memory; 

calling the memory manager: 

by operation of the memorv* manager, allocating space in memor>' sufficient to 
1 0 store the new data record: 

calling the file manager: 

by operation of the file manager, defining the new data record in the allocated 
memor\' space. 

40. The method of claim 39. wherein the memor\' manager allocates memor\ by 
15 reference to a memory management record, the method further comprising: 

following allocation of the memory space by the memory manager, updating the 
memory management record to indicate the presence of the new data record. 

41 . The method of claim 39, wherein the file manager organizes data records in 
memor\' using a file directory, the method further comprising: 

-0 following definition of the new record by the file manager record in the allocated 

memor>' space, updating the file director.' to indicate the presence of the new data record. 
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